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The  Department  of  Defense  began  using  integrated  product 
teams  (IPTs)  in  weapons  development  in  the  1980s.  Their  use 
proliferated  after  the  secretary  of  Defense  directed  their  use 
under  the  integrated  product  and  process  development  (IPPD) 
concept  in  1995.  Over  the  years,  the  term  IPT  has  been  applied 
to  a  variety  of  groups,  councils,  tiger  teams,  and  boards.  Although  these 
groups  all  have  important  functions,  the  IPT  is  a  specific  and  power¬ 
ful  tool  that  begs  definition.  Properly  chartered,  an  IPT  is  a  protection 
against  obstacles  to  success  I've  observed  in  acquisition  program  offices: 
parochialism,  functional  bias  and  poor  communication,  to  name  a  few. 
These  obstacles  existed  in  spite  of  the  fact  that  the  people  involved  were 
dedicated,  experienced,  and  patriotic. 

I  was  assigned  to  a  major  defense  acquisition  aircraft  program  that  had  operated 
under  strong,  capable,  experienced  functional  alignment.  The  program  office  floor 
space  had  been  physically  arranged  into  functional  areas:  program  management, 
engineering,  contracting,  logistics,  testing,  financial  management,  training  systems, 
manufacturing,  security,  and  administration,  each  headed  by  a  GS-15  or  colonel.  There 
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The  charter  had  to  be 
specific,  not  at  high 
level,  not  vague  or 
timid.  It  had  to  contain 
milestones,  outcomes, 
or  specific  objectives. 


were  SES-level  functional  heads  at  the  base  level  to  which 
these  functional  chiefs,  and  those  in  other  program  offices  on 
base,  reported.  There  were  also  user  representatives  from  the 
combat  commands  on  base. 

When  a  major  issue,  such  as  a  proposed  design  change,  arose 
in  the  program  office,  each  functional  chief  would  assemble 
his  functional  team  and  formulate  their  best  position  on  the 
issue.  Each  functional  position  then  would  be  presented  in  a 
staff  meeting  to  the  program  manager,  who  would  eventu¬ 
ally  make  the  decision  on  how  to  proceed.  Next,  the  deputy 
program  manager  and  chief  of  contracting  would  travel  to  the 
prime  contractor  to  present  the  decision.  One  of  the  user  reps 
would  check  back  with  their  combat  command  headquarters. 
The  program  manager  ran  the  program  by  being  the  arbiter 
among  valid  but  competing  positions  among  his  functional 
chiefs,  sorting  out  issues  at  his  level. 

I  was  assigned  to  the  program  office  about  the  same  time  that 
a  new  program  manager,  a  general  officer,  was  assigned.  The 
general  quickly  became  overwhelmed  with  having  to  deter¬ 
mine  the  best  direction  for  the  aircraft  program  while  being 
faced  with  conflicting  recommendations  from  his  functional 
chiefs,  often  in  areas  where  he  had  little  experience  himself. 
He  sensed  that  program  decisions  had  been  made  in  the  past 
based  on  the  strength  of  arguments  and  personalities.  He 
believed  this  was  not  always  the  best  balanced  approach  for 
the  airplane  program  overall,  nor  the  most  efficient  applica¬ 
tion  of  the  program  office  expertise.  The  program  manager 
had  just  come  from  a  base  that  had  undertaken  a  base-wide 
transformation  to  IPTs  in  their  program  offices.  This  had  in¬ 
volved  extensive  training,  but  it  had  paid  off  in  efficiency  and 
effectiveness,  and  he  determined  it  was  time  it  install  IPTs  in 
his  program  office. 

At  first  there  was  some  unease  with  the  program  manager's 
IPT  initiative,  but  that  diminished  as  the  functional  chiefs 


each  volunteered  to  lead  an  IPT.  That  is  where  things  got 
Interesting.  The  program  manager  was  firm  that  IPTs  would 
be  chartered  by  him  to  manage  or  produce  a  product,  such  as 
a  test  plan  or  engine,  or  a  major  subsystem.  Rather  than  be  an 
engineering  team  or  contracting  team,  the  I  PTs  were  to  repre¬ 
sent  a  product,  not  a  function.  There  would  be  no  engineering 
solutions  or  logistics  positions  or  testing  imperatives.  There 
would  only  be  a  team  solution  for  the  product,  balancing  all 
functional  inputs  at  the  working  level.  The  IPT  organization 
would  replace  the  functional  organization  process  of  handing 
off  a  product  from  one  stovepipe  to  another— from  engineer¬ 
ing  to  manufacturing  to  logistics,  and  back  again. 

He  expected  his  functional  chiefs  to  take  on  a  new  respon¬ 
sibility.  They  were  to  help  him  identify  key  products  or  areas 
in  the  weapon  system  that  needed  an  IPT.  The  manning  de¬ 
mand  for  IPTs  required  they  be  few  as  possible  in  number 
and  cover  major  products.  They  didn't  need  a  seat  cushion 
IPT.  They  were  to  then  help  write  a  charter  for  each  IPT.  Then 
identify  members  from  each  functional  discipline  needed  on 
the  IPT.  Next,  the  functional  heads  were  to  empower  the 
members  they  put  on  an  IPT.  No  running  back  to  the  chief 
engineer  for  mother-may-1.  And  there  was  no  space  for  ob¬ 
servers,  only  necessary  contributors.  (I  am  reminded  of  a 
senior  acquisition  official  who  said  she  only  wanted  members 
on  herteam  who  would  lose  their  jobs  if  the  team  failed.  The 
message  was  no  hangers-on,  no  observers,  and  no  kibitzers.) 
The  IPT  concept  was  decision  making  and  execution  at  the 
lowest  level. 

The  program  manager  expected  some  resistance.  He  remem¬ 
bered  at  his  previous  base  the  IPT  concept  had  required  buy-in 
from  the  senior  functional  heads  on  base,  and  the  senior  of¬ 
ficers  at  the  base.  So  he  met  with  each  senior  stakeholder  on 
base.  He  explained  to  the  senior  leaders  something  that  he 
had  discovered.  The  program  was  in  trouble,  but  no  one  was 
accountable.  The  best  example  of  the  trouble  was  the  test 
schedule  for  the  electronic  countermeasures  (ECM)  system 
was  not  being  met. 

The  logistics  functional  group  would  not  agree  to  allow  test¬ 
ing  to  proceed  until  the  important  maintainability  features 
were  included  early  in  the  test  schedule.  The  engineering 
group  stated  that  testing  must  be  held  up  until  certain  engi¬ 
neering  questions  were  worked  out.  The  testing  organization 
was  not  willing  to  proceed  until  all  testing  criteria  met  their 
developmental  testing  objectives.  The  program  manager 
pointed  out  that  in  this  example— and  there  were  many  oth¬ 
ers— there  was  validity  to  each  position.  But  there  was  no  one 
accountable  for  the  product,  in  this  case,  the  ECM  system. 

He  viewed  the  responsibility  of  each  senior  head  to  be  to  get 
the  airplane  to  the  warfighter.  To  do  that  he  would  use  IPTs 
and  he  solicited  their  help.  The  senior  functional  and  base 
leaders  agreed  to  support  him,  but  not  without  reservations 
and  concerns,  and  doubts.  After  some  discussion,  they  agreed 
to  exercise  their  functional  responsibilities  by  seeing  that  the 
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right  functional  experts  were  assigned  to  the  right  IPTs.  They 
agreed  to  offer  sound  balanced  processes  to  their  IPT  mem¬ 
bers,  but  let  them  manage  the  products. 

Here  is  what  the  program  manager  believed  I  PTs  were  and  what 
they  were  not.  The  letters  in  "IPT”  have  defined  meanings. 

Integrated  means  the  team  is  composed  of  every  specialty  or 
discipline  needed  to  deliver  the  product.  I  was  appointed  lead 
for  the  ECM  IPT.  This  IPT  also  needed  domain  representatives 
in  development,  test,  manufacturing,  contracting,  budgeting, 
integration,  deployment,  and  sustainment.  The  team  included 
the  user  and  the  contractor  during  all  meetings  and  delibera¬ 
tions,  not  as  an  afterthought. 

Product  means  the  team  is  responsible  for  a  product.  It  is  not 
a  review  group  to  monitor  progress  or  a  tiger  team  to  address 
a  single  problem.  The  product  may  be  a  piece  of  equipment  or 
a  test  plan,  but  a  product  must  be  defined.  In  my  case  it  was 
the  ECM  system  that  would  be  provided  as  government  fur¬ 
nished  equipment  (GEE)  to  the  prime  contractor  to  integrate 
into  the  airplane. 

Team  means  that  the  members  work  for  consensus.  A  team 
has  one  leader.  I  was  a  leader  among  peers,  regardless  of  rank 
or  function.  Each  member  had  equal  say.  As  leader  I  did  not 
have  a  technical  or  functional  responsibility.  My  job  was  to 
see  that  the  team  delivered  a  product  that  balanced  factors 
from  all  members,  to  see  the  team  reach  consensus.  To  op¬ 
erate  best  the  team  members  are  collocated,  with  their  own 
meeting  area. 

The  first  step  was  to  determine  the  IPTs.  The  program  man¬ 
ager  and  his  functional  chiefs  decided  which  major  products  or 
components  needed  direct  management  by  an  IPT.  Next  they 
took  the  necessary  time  to  carefully  craft  a  charter  for  each 
IPT.  The  charter  had  to  be  specific,  not  at  high  level,  not  vague 
or  timid.  It  had  to  contain  milestones,  outcomes,  or  specific 
objectives.  The  charter  had  to  state  the  IPT's  authority  and  the 
next  level  of  reporting  for  the  IPT.  The  program  manager  and 
his  chiefs  named  in  the  charter  an  IPT  lead  whose  responsibili¬ 
ties  were  stated,  which  did  not  include  any  functional  responsi¬ 
bilities.  Finally  the  charter  was  signed  by  the  program  manager. 
Each  charter  was  eventually  posted  in  the  IPT's  team  area. 

Next  came  the  naming  of  IPT  members.  Each  must  be  re¬ 
lieved  of  other  duties  sufficiently  to  accomplish  the  objectives 
in  the  charter.  The  chiefs  had  to  assure  the  approval  of  the 
individual's  supervisory  chain.  Finally,  the  IPT  members  must 
be  empowered  to  do  what  is  in  the  charter. 

There  are  a  few  tips  I  learned  as  an  IPT  lead. 

The  IPT  leader  must: 

■  Be  respected  in  and  out  of  the  IPT 

■  Be  balanced 


■  Possess  managerial  skills 

■  Be  able  to  manage  the  external  environment  to  allow  the 
I PT  to  focus  on  their  work 

■  Be  decisive.  Make  the  decision  with  the  best  consensus 
when  the  decision  must  be  made 

■  Not  be  biased  toward  any  functional  or  technical  viewpoint 

The  IPT  members  must: 

■  Have  domain  or  functional  expertise 

■  Be  empowered  and  have  authority  for  their  domain 

■  Be  committed  to  the  IPT's  product  and  charter 

■  Agree  on  ground  rules,  time  demands  and  schedules 

■  Be  open  minded 

■  Be  a  team  player 

Not  every  program  office  will  be  able  arrange  all  the  particu¬ 
lars  I  illustrated  above,  but  the  core  functions  are  achievable. 
You  may  not  have  the  luxury  of  dedicated  meeting  rooms, 
but  you  can  schedule  common  meeting  spaces.  You  may 
not  have  all  members  collocated,  but  there  are  ways  to  still 
meet  together  using  travel,  video  teleconferencing,  or,  as  a 
last  resort,  speaker  phones.  The  essential  requirement  is  that 
all  IPT  members  be  present  at  meetings.  You  may  not  be  able 
to  have  (or  even  need)  full-time  access  to  every  functional 
expert  called  for,  but  you  must  push  for  dedicated  identified 
members,  even  if  part  time.  Two  mandatory  members  of  your 
IPT— and  this  is  essential— are  the  user  and  the  contractor. 
If  your  IPT  is  for  a  GFE  component,  you  need  both  the  GFE 
vendor  and  the  prime  contractor. 

There  were  other  tasks  the  general  faced  to  implement  IPTs. 
The  facility  manager  had  to  rearrange  the  cubicles  so  the  IPT 
members  could  sit  together,  and  so  that  each  IPT  had  a  meet¬ 
ing  area.  The  head  of  human  resources  had  to  agree  to  permit 
each  IPT  lead  to  make  written  input  to  the  appraisals  and  per¬ 
formance  reports  of  his  IPT  members,  such  as  by  formal  letter 
to  the  member's  supervisor  of  record. 

The  IPT  was  tasked,  recognized,  and  rewarded  as  a  team,  not 
as  individuals. 

At  first  there  was  some  uneasiness  and  mistrust  among  the 
IPT  members.  But  as  they  began  to  meet  and  solve  problems 
together  I  witnessed  an  interesting  phenomenon.  They  began 
to  achieve  successes.  Small  organizational  successes  at  first, 
but  then  they  began  to  tackle  and  solve  bigger  challenges. 
They  began  to  learn  each  other's  jobs.  They  became  able  to 
answer  outside  inquiries  for  each  other  when  a  member  was 
not  available.  They  began  to  cover  for  each  other. 

IPTs  do  not  arise  automatically,  or  naturally,  or  spontane¬ 
ously  out  of  need.  Nor  are  they  learned  on  the  fly.  They  must 
be  worked  at  to  work.  There  are  a  variety  of  people  who  can 
and  will  say  no  to  an  idea.  IPT  members  are  empowered  to 
say  yes. 

The  author  can  be  reached  at  david.hofstadter^dau.mil. 
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